<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>blog</title>
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1 , user-scalable=no">
    <script src="../js/jquery-3.0.0.min.js"></script>
    <link rel="stylesheet" href="../bootstrap-3.3.7-dist/css/bootstrap.css">
    <script src="../bootstrap-3.3.7-dist/js/bootstrap.min.js"></script>
	<link rel="stylesheet" href="../css/blog.css">
</head>
<body>
	<!-- nav导航栏 -->
<nav class="navbar navbar-default">
  <div class="container-fluid">
    <div class="navbar-header">
      <button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1" aria-expanded="false">
        <span class="sr-only">Toggle navigation</span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
        <span class="icon-bar"></span>
      </button>
      <a class="navbar-brand" href="../index.html">Jenkies</a>
    </div>
<!-- 左边 -->
    <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
      <ul class="nav navbar-nav">
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false" id="logcd">cd <span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">One more separated link</a></li>
          </ul>
        </li>
      </ul>
      <ul class="nav navbar-nav navbar-right">
        <li><a href="#">Blog</a></li>
        <li><a href="#">Documentation</a></li>
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Dropdown <span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
          </ul>
        </li>
        <li><a href="#">Plugins</a></li>
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Community <span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
          </ul>
        </li>
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Subprojects<span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
          </ul>
        </li>
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">About<span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
          </ul>
        </li>
        <li class="dropdown">
          <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Engish<span class="caret"></span></a>
          <ul class="dropdown-menu">
            <li><a href="#">Action</a></li>
            <li><a href="#">Another action</a></li>
            <li><a href="#">Something else here</a></li>
            <li role="separator" class="divider"></li>
            <li><a href="#">Separated link</a></li>
          </ul>
        </li>
        <li>
        <a class="nav-link btn btn-outline-secondary" href="">Download</a>
        </li>
      </ul>
    </div>
  </div>
</nav>

<!-- 内容 -->
<div class="blog">
  <div class="container">
    <div class="row body">
        <div class="col-md-1"></div>
        <div class="col-md-10">
          <div class="item-list" >
             <h1>Jenkins Community Blog</h1>
             <div id="introduce">
             	The Jenkins project has a lot going on between core/plugin development, events and other open source automation related activities. To keep up with it subscribe to our<a href="">RSS feed</a> or <a href="">follow</a> us on <a href="">Twitter</a>
             </div>
              <ul>
                <li class="post">
                  <a class="body" href="">
                      <div class="header">
                        <div class="date">
                          <div class="month">Dec</div>
                          <div class="day">16</div>
                        </div>
                        <h5 class="title">Jenkins 健康检查顾问</h5>
                      </div>
                      <p class="teaser">
                          管理任何软件都面临着独特的挑战。Jenkins Masters 也不例外。例如，
                          您如何掌握 Jenkins 环境中发生的所有事情？您是否正在查看问题跟踪器中打开的每个新缺陷？
                          您如何确保您的 master 或 agents 不会默默失效？您是否正在监控其日志？监控其所有内部组件？如果出现问题，您该如何解决？
                          您如何避免出现 “Angry Jenkins” 图标？
                          这就是我们通过 CloudBees 创建 Jenkins Health Advisor 的原因。
                          在 CloudBees，我们拥有多年为使用 Jenkins 的客户提供支持的经验，其中包括基于 Jenkins 构建的专有产品，例如 CloudBees Core。因此，我们的支持团队由拥有 Jenkins 知识的自动化专家组成，您在其他任何地方都无法获得。
                          当我们的工程师创建一个平台时，便会开始自动运行状况检查，以便他们可以编写规则来检测客户提供的 support bundles 中的已知问题，并将其重定向到所需的知识源以诊断和解决问题。
                          经过多年的内部使用，我们决定与社区共享此服务，我们很高兴为 每个 Jenkins 用户推出一项新的免费服务：Jenkins Health Advisor by CloudBees。
                          Jenkins Health Advisor by CloudBees 自动分析您的 Jenkins 环境，主动识别潜在问题，并通过详细的电子邮件报告为您提供解决方案和建议。
                          Jenkins Health Advisor by CloudBees 可以检测到各种问题，从简单的配置问题到安全性和最佳实践问题-Jenkins 实现的所有关键要素。入门过程分为 3 个步骤，您将在 24 小时内收到第一份报告。
                          我们希望您会喜欢这项服务，它将帮助您保持 masters 的健康。
                          花几分钟时间阅读我们的文档，发现服务，并随时通过 Jenkins 社区渠道（Gitter、jenkinsci-users@googlegroups.com，…）与我们联系。
                          也不要错过在 DevOps World|Jenkins World 2019上与我们的支持团队会面的机会。
                          参考链接：
                          插件文档
                          Jenkins 插件网站
                          CloudBees Jenkins...
                          <span class="more"></span>
                      </p>
                  </a>
                    <div class="attrs">
                        <a href="" class="tip">Arnaud Héritier</a>
                        <ul class="list-inline tags">
                          <li>
                            <a class="tag-link" href="">Jenkins</a>
                          </li>
                          <li>
                            <a class="tag-link" href="">CloudBees</a>
                          </li>
                        </ul>
                      </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/blog/2020/07/09/github-checks-api-plugin-coding-phase-1/">
                    <div class="header">
                      <div class="date">
                        <div class="month">Jul</div>  
                        <div class="day">09</div>
                      </div>
                      <h5 class="title">介绍新文件授权插件</h5>
                    </div>
                    <p class="teaser">
                      在我的 Google Summer of Code Project 期间，我创建了全新的 Folder Auth 插件，可轻松管理 Folders plugin 对文件夹中组织的项目的权限。这个新插件旨在通过易于管理的角色进行快速权限检查。该插件的 1.0 版本刚刚发布，可以从您的 Jenkins 更新中心下载。
                      该插件的灵感来自角色策略插件，可改善性能并简化角色管理。开发该插件是为了解决 Role Strategy Plugin 在许多角色上的性能限制。同时，该插件通过文件夹解决了 Jenkins 中组织项目最受欢迎的方式之一。该插件还具有一个新的 UI，将来会有更多改进。
                      该插件支持三种类型的角色，分别适用于 Jenkins 中的不同位置。
                      * 全局角色：适用于 Jenkins 的所有地方
                      * 代理角色：限制连接到您的实例的多个代理的权限
                      * 文件夹角色：适用于文件夹内组织的多个作业
                      角色策略插件的性能改进
                      与角色策略插件不同，此插件不使用正则表达式来查找匹配的项目和代理，从而改善了我们的性能并简化了管理员的工作。为了减少需要管理的角色数量，通过文件夹角色授予文件夹的权限将继承其所有子项。这对于通过单个角色访问多个项目很有用。同样，一个代理角色可以应用于多个代理，并分配给多个用户。
                      此插件的设计目的是在权限检查方面优于角色策略插件。这些改进是使用我在 GSOC 项目的第一阶段创建的 micro-benchmark framework 来衡量的。两个插件相同配置的基准测试表明，与角色策略 2.13 中的全局角色相比，500 个全局角色的权限检查速度提高了 934 倍，角色策略 2.13 本身包含一些性能改进。将文件夹角色与角色策略的项目角色进行比较，对于 250 个组织在 150 个用户的实例上的两级深层文件夹中的项目，对作业的访问权限检查几乎快了 15 倍。您可以在 此处 看到基准和结果比较。
                      Jenkins 配置作为代码支持
                      该插件支持 Jenkins 的“代码即配置”功能，因此您无需通过 Web UI 即可配置权限。YAML 配置如下所示：
                      jenkins:authorizationStrategy:folderBased:...
                      <span class="more"></span>
                    </p>
                  </a>
                  <div class="attrs">
                    <a href="/blog/authors/xiongkezhi" class="tip">Kezhi Xiong</a>
                    <ul class="list-inline tags">
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/github">github</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/api">api</a>
                      </li>
                      <li>
                       <a class="tag-link" href="https://www.jenkins.io/node/tags/plugins">plugins</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/developer">developer</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc">gsoc</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc2020">gsoc2020</a>
                      </li>
                    </ul>
                  </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/blog/2020/07/08/winsw-yaml-support/">
                    <div class="header">
                      <div class="date">
                        <div class="month">Jul</div>
                        <div class="day">08</div>
                      </div>
                      <h5 class="title">插件文件即代码:将文件迁移到github</h5>
                    </div>
                    <p class="teaser">
                      在2019年9月，我们宣布了
                      对 GitHub 作为 Jenkins 插件站点文档来源的支持。
                      感谢 Zbynek Konecny 和 Olivier Vernin 以及其他贡献者，
                      现在可以将插件文档直接存储在插件储存库中，而不是 Jenkins Wiki 中，对于插件维护者和 Jenkins 基础设施团队来说，这在过去是很难维护的
                      这篇博文可能对插件维护者和那些想为 Jenkins 文档做贡献的人来说很有趣。
                      我将描述如何将插件文档迁移到 GitHub 并获得如下页面:
                      为什么？
                      通过使用插件的 GitHub 仓库存储文档，
                      插件维护者可以遵循 文档即代码 的方法，将文档更改作为 pull request 的一部分，这样就不会忘记文档的后续工作。
                      它还提供了一个 review 文档更改以及增加文档贡献者的认可度的机会，尤其是如果 story 与 Release Drafter 结合。
                      不幸的是，在2019年9月之前，GitHub 文档的使用引起了一些问题。
                      首先，许多插件维护者已经将他们的文档迁移到 GitHub，这导致了文档的碎片化（Wiki、GitHub、jenkins.io）。
                      为了解决这个问题，插件维护者仍然需要使用重定向来维护存根 Wiki 页面，
                      用户不得不花一些时间来找出真正的文档在哪里。
                      通过支持 GitHub 作为文档来源，我们允许维护者逐步淘汰插件 Wiki 页面，同时改善用户体验。
                      现在进行迁移还有更紧迫的原因……
                      <span class="more"></span>
                    </p>
                  </a>
                  <div class="attrs">
                    <a href="/blog/authors/buddhikac96" class="tip">Buddhika Chathuranga</a>
                    <ul class="list-inline tags">
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/winsw">winsw</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/windows">windows</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/jenkins">jenkins</a>
                      </li>
                      <li>
                      <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc">gsoc</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc2020">gsoc2020</a>
                      </li>
                    </ul>
                  </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/blog/2020/06/30/machine-learning-plugin-coding-phase1/">
                  <div class="header">
                    <div class="date">
                      <div class="month">Jun</div>
                      <div class="day">30</div>
                    </div>
                    <h5 class="title">React Plugin Template</h5>
                  </div>
                  <p class="teaser">
                    模板地址
                    React Plugin Template
                    起因
                    这个模板是笔者在今年的 Google Summer of Code 中的项目 Working Hours - UI Improvement 中产出的。由于我们想使用 React 的一些组件来优化用户体验，例如在 Working Hours 里面我们想用 ReactDatepicker 来帮助用户选择日期，于是整个 Working Hours 插件的前端部分都试图用 React 来编写，而由于 Jenkins 的传统插件编写主要还是用的 Jelly ，一套类似 JSP 的后端渲染引擎，因此笔者在一开始也踩了不少坑。以至于想到，可以抽象出一套插件的脚手架来帮助有相似需求的同学。
                    链接：
                    GSoC：Working Hours UI Improvement https://summerofcode.withgoogle.com/projects/#6112735123734528
                    Github：Working Hours 插件 https://github.com/jenkinsci/working-hours-plugin
                    概述
                    在以往，我们可以使用 Jelly 来开发 Jenkins 插件的前端部分，同时一些请求可以绑定到对应的类，但是当我们想要更高程度地去自定义插件界面的时候，Jelly 就显得捉襟见肘了。这就是这个模板的目的，帮助开发者使用 React 来开发一个插件。
                    同时，有了 React ，我们就可以使用很多基于 React 的库，webpack 也可以帮助我们更安全更高效地使用 js 库。
                    特点
                    集成 React
                    开发者可以使用 React 充分控制 UI
                    使用了 Iframe
                    Iframe 隔离了之前 Jenkins 添加的一些 js 库会造成的影响，例如 Prototype.js。
                    使用...
                    <span class="more"></span>
                  </p>
                  </a>
                  <div class="attrs">
                    <a href="/blog/authors/loghijiaha" class="tip">Loghi Perinpanayagam</a>
                    <ul class="list-inline tags">
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/machinelearning">machinelearning</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/datascience">datascience</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/plugins">plugins</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/communitybonding">communitybonding</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc">gsoc</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc2020">gsoc2020</a>
                      </li>
                    </ul>
                  </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/blog/2020/06/27/external-fingerprint-storage/">
                  <div class="header">
                    <div class="date">
                      <div class="month">Jun</div>
                      <div class="day">27</div>
                    </div>
                    <h5 class="title"> 利用 jcli 管理 Jenkins</h5>
                  </div>
                  <p class="teaser">
                    作为一名开发者，我通常像下面那样使用 Jenkins：
                    查找与我当前工作相关的任务
                    触发任务构建
                    检查构建日志
                    有时候，我可能需要检查插件更新中心，安装新的插件，或者更新一个已有的插件。再或者，希望从本地上传一个插件。所有的这些情况，其实都没有必要
                    访问 UI 界面甚至是浏览器。我更倾向于使用命令行（CLI）来完成大部分的工作。例如：我可以使用 kubectl 来管理我的 Kubernets 集群，
                    创建或者修改 Kubernetes 资源。因此，我开始思考，“为什么不用命令行来管理 Jenkins 呢”？
                    什么要创造新的轮子？
                    首先，我几乎都已经忘记了那个早已存在的命令行，用 Java 编写的 Jenkins CLI。让我先
                    介绍一下如何使用这个命令行。
                    访问 Jenkins 的页面 http://localhost:8080/jenkins/cli/。你将会看到类似于 java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ help 的命令行。因此，需要下载一个 jar 文件。我们可以用命令 wget http://localhost:8080/jenkins/jnlpJars/jenkins-cli.jar 来下载。
                    此时，你应该能看到，这并不是一个 Linux 风格的 CLI。请思考下面的几个点：
                    用户必须要有一个 JRE 环境。这对于非 Java 开发者来说并不方便。
                    命令行使用繁琐，需要输入很多字符。我们每次都需要输入 java -jar jenkins-cli.jar -s http://localhost:8080/jenkins/ 作为命令的前缀。
                    无法使用一些流行的包管理器安装，例如：brew 或 yum。
                    当然，Java 版本的命令行和 Jenkins 的兼容性更好。但是，我期望在使用时可以更简单些。
                    因此，我决定使用 Golang 来编写一个新的命令行，这样可以运行在多个平台上。
                    这就是创建 jcli 的故事。
                    特性
                    易于维护的 jcli 配置文件
                    支持管理多个 Jenkins
                    插件管理（列表、搜索、安装、上传）
                    任务管理（搜索、构建、日志）
                    在浏览器中打开 Jenkins
                    重启 Jenkins
                    支持连接代理
                    如何获取？
                    你可以从 jenkins-cli 的代码仓库中克隆 jcli。目前，我们支持三个主流的操作
                    系统平台： MacOS、Linux、和 Windows。
                    MacOS
                    你可以使用 brew...
                    <span class="more"></span>
                  </p>
                  </a>
                  <div class="attrs">
                    <a href="/blog/authors/stellargo" class="tip">Sumit Sarin</a>
                    <ul class="list-inline tags">
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/plugins">plugins</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/fingerprint">fingerprint</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/cloud-native">cloud-native</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/external-storage">external-storage</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/developer">developer</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/redis">redis</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc">gsoc</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/node/tags/gsoc2020">gsoc2020</a>
                      </li>
                    </ul>
                  </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/zh/blog/2019/08/23/introducing-gitlab-branch-source-plugin/">
                    <div class="header">
                      <div class="date">
                        <div class="month">Aug</div>
                        <div class="day">23</div>
                      </div>
                      <h5 class="title">介绍新的 GitLab 分支源插件</h5>
                    </div>
                    <p class="teaser">
                      GitLab 分支源插件已经走出 beta 阶段，并已发布到 Jenkins 更新中心。
                      它允许您基于 GitLab 用户 或 组 或 子组 项目创建任务。
                      您可以:
                      从 GitLab 用户/组/子组导入单个项目的分支作为任务（多分支流水线任务）
                      从 GitLab 用户/组/子组导入所有或部分项目的分支作为任务（GitLab 组任务或 GitLab 文件夹组织）
                      GitLab 组项目对项目进行扫描， 根据设置的规则导入流水线任务。
                      导入项目之后， Jenkins 立即基于 Jenkinsfile 流水线脚本运行任务并且将状态通知到 GitLab 流水线状态。
                      这个插件与其他分支源插件不同，它提供了 GitLab 服务器配置，可以在系统配置中配置。
                      Jenkins 配置即代码 (JCasC) 也可以用于配置服务器。
                      要想了解更多关于服务器配置的信息，请参考我之前的博客。
                      要求
                      Jenkins - 2.176.2 (LTS)
                      GitLab - v11.0+
                      创建任务
                      要创建多分支流水线任务（使用 GitLab 分支源）或 GitLab 组任务，您必须将 GitLab 个人访问令牌添加到服务端配置。
                      凭据用于获取项目的元数据，并在 GitLab 服务器上设置 hook。
                      如果令牌具有管理访问权限，您还可以设置 系统 Hook，而 Web Hook 可以从任何用户令牌设置。
                      创建多分支流水线任务
                      转到 Jenkins &gt; 新建任务 &gt; 多分支流水线 &gt; 添加源 &gt; GitLab 项目
                      Server - 从下拉菜单中选择所需的...
                      <span class="more"></span>
                      </p>
                  </a>
                  <div class="attrs">
                    <a href="/blog/authors/stellargo" class="tip">bymac</a>
                    <ul class="list-inline tags">
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/gitlab">gitlab</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/plugins">plugins</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/pipeline">pipeline</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/multibranch">multibranch</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/gsoc">gsoc</a>
                      </li>
                      <li>
                        <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/gsoc2019">gsoc2019</a>
                      </li>
                    </ul>
                  </div>
                </li>
                <li class="post">
                  <a class="body" href="https://www.jenkins.io/zh/blog/2019/07/15/pipeline-config-history-plugin/">
                  <div class="header">
                    <div class="date">
                      <div class="month">Jul</div>
                      <div class="day">15</div>
                    </div>
                  <h5 class="title">流水线配置历史插件介绍</h5>
                  </div>
                    <p class="teaser">
                    流水线是在 Jenkins 中创建任务的有效的和现代的方式。
                    为了快速、简单地识别流水线变更，我们开发了流水线配置历史插件。
                    这个插件检测流水线的变更，并为用户提供一个选项，以明显地、可追溯地查看流水线配置两次构建（差异）之间的变更。
                    一切是如何开始的
                    这一切开始于十年之前 —— 经典的任务类型 (例如：自由风格、Maven 等等)。
                    每隔一段时间，用户就会联系我们，因为他们的任务无法在一夜之间完成。
                    为什么这个任务失败了呢？
                    这次失败和任务配置变更有关系吗？
                    用户典型的回答是："我们没有改任何东西"，但这是真的吗？
                    我们思考了这个问题，并决定开发一个插件来帮助我们解决这个问题。
                    这就是任务配置历史的想法和开始。
                    现在可以查看任务配置的变更(例如其他分支、JDK版本等)，而且更常见的情况是，破坏构建的原因是任务配置的变更。
                    多年来，该插件得到了开发，目前仍在开发中。
                    添加了新的功能，不仅可以查看任务配置，还可以查看全局和代理配置的变更。
                    还可以恢复旧的配置版本。
                    如今，这个插件已经有超过30,000次安装量。
                    多年来，JobConfigHistory 减轻了我们的日常工作 —— 有超过3000个 Jenkins 任务！
                    然后出现了一种新的任务类型：流水线。
                    流水线 —— 需要一些新的东西
                    流水线任务和经典的任务类型有根本地区别。
                    经典的任务类型是通过 Jenkins GUI 配置的，而流水线任务是配置即代码。
                    实际上，每个流水线任务都是通过 Jenkins GUI 创建的，然而这并不一定是流水线配置的位置。
                    流水线可以被配置：
                    直接在 Jenkins 任务中作为脚本。
                    代码将直接插入任务配置页面。
                    作为源代码管理系统（SCM）中的 Jenkinsfile：流水线配置在 SCM 中的文本文件（Jenkinsfile）中定义。
                    在任务本身中，只配置了 Jenkinsfile 存储库的路径。
                    在构建过程中，Jenkinsfile 从 SCM 中被检出并被处理。
                    作为共享库：流水线配置的一部分被移动到单独文件中，它可以由多个任务使用。
                    这些文件也保存在 SCM 中。
                    即使这样仍然需要 Jenkinsfile（或者任务中的流水线脚本）。
                    对于任务配置的每次保存操作，如果发生了变更，JobConfigHistory 将创建实际任务配置的副本。
                    只有当流水线配置作为脚本插入到任务配置页面时，该方法才适用于流水线任务。
                    JobConfigHistory 未检测到 Jenkinsfile 或共享库中的变更。
                    您必须使用 SCM 系统查看 Jenkinsfile 或共享库的变更。
                    在构建时间和对 Jenkinsfile 或共享库的变更之间找到相关性是复杂且耗时的。
                    这个新问题不仅仅是 JobConfigHistory。
                    需要一个新的解决方案来检测流水线变更并显示 Jenkins 中的这些变更。
                    所以我们开发了流水线配置历史插件。
                    在每个流水线运行期间，Jenkinsfile 和相关的共享库都保存在任务的`构建`目录中。
                    流水线配置历史插件将最近运行和前一次运行之间流水线文件的变更保存为历史事件。
                    因此，当流水线任务以成功的构建结束时，您可以检查任何使用的流水线文件是否发生了变更。
                    您还可以看到发生变更的构建。
                    因为流水线配置可以由可能发生变更的多个文件组成，所以 diff 中只显示两个构建版本之间发生变更的文件。
                    这使得整个过程更加紧凑和有效：
                    但有时您可能想要显示的不仅仅是流水线文件之间的差异。
                    您可能希望查看哪些流水线文件正在使用，或者这些文件在使用时的内容。
                    因此可以查看所有文件及其内容。
                    如果需要，您也可以下载：
                    结论
                    我们在生产中成功地使用了流水线配置历史插件。
                    它从第一天起就帮助我们解决了由于流水线配置变更而出现的问题。
                    流水线配置历史插件不会替换任务配置历史插件。
                    插件有不同的用例。
                    很多时候，任务或流水线配置上的小变更也会产生很大的影响。
                    由于任务或流水线配置的变更与不同的构建行为之间的时间相关性，现在可以大大减少分析构建失败的时间和精力。
                    任务配置历史和流水线配置历史插件允许我们在咨询和解决问题方面为用户提供帮助。通过访问任务的配置历史，我们可以更快地解决问题。这些插件对我们的日常工作是必不可少的。...
                    <span class="more"></span>
                    </p>
                  </a>
                  <div class="attrs">
                  <a href="" class="tip">pch-maintainers</a>
                  <ul class="list-inline tags">
                    <li>
                      <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/pipeline">pipeline</a>
                    </li>
                    <li>
                      <a class="tag-link" href="https://www.jenkins.io/zh/node/tags/plugins">plugins</a>
                    </li>
                  </ul>
                  </div>
                </li>
              </ul>
          </div>
        </div>
        <div class="col-md-1"></div>
    </div>
    <!-- 分页 -->
	 <div class="pagination">
	  <ul>
	    <li><a href="#">Prev</a></li>
	    <li><a href="#">1</a></li>
	    <li><a href="#">2</a></li>
	    <li><a href="#">3</a></li>
	    <li><a href="#">4</a></li>
	    <li><a href="#">5</a></li>
	    <li><a href="#">Next</a></li>
	  </ul>
	</div>
  </div>
</div>




</body>
</html>